home *** CD-ROM | disk | FTP | other *** search
/ Chip 1998 September / CHIP Eylül 1998.iso / Slackwar / docs / linux-2.0.34 / BUG-HUNTING < prev    next >
Text File  |  1996-04-11  |  4KB  |  93 lines
  1. [Sat Mar  2 10:32:33 PST 1996 KERNEL_BUG-HOWTO lm@sgi.com (Larry McVoy)]
  2.  
  3. This is how to track down a bug if you know nothing about kernel hacking.  
  4. It's a brute force approach but it works pretty well.
  5.  
  6. You need:
  7.  
  8.         . A reproducible bug - it has to happen predictably (sorry)
  9.         . All the kernel tar files from a revision that worked to the
  10.           revision that doesn't
  11.  
  12. You will then do:
  13.  
  14.         . Rebuild a revision that you believe works, install, and verify that.
  15.         . Do a binary search over the kernels to figure out which one
  16.           introduced the bug.  I.e., suppose 1.3.28 didn't have the bug, but 
  17.           you know that 1.3.69 does.  Pick a kernel in the middle and build
  18.           that, like 1.3.50.  Build & test; if it works, pick the mid point
  19.           between .50 and .69, else the mid point between .28 and .50.
  20.         . You'll narrow it down to the kernel that introduced the bug.  You
  21.           can probably do better than this but it gets tricky.  
  22.  
  23.         . Narrow it down to a subdirectory
  24.  
  25.           - Copy kernel that works into "test".  Let's say that 3.62 works,
  26.             but 3.63 doesn't.  So you diff -r those two kernels and come
  27.             up with a list of directories that changed.  For each of those
  28.             directories:
  29.  
  30.                 Copy the non-working directory next to the working directory
  31.                 as "dir.63".  
  32.                 One directory at time, try moving the working directory to
  33.                 "dir.62" and mv dir.63 dir"time, try 
  34.  
  35.                         mv dir dir.62
  36.                         mv dir.63 dir
  37.                         find dir -name '*.[oa]' -print | xargs rm -f
  38.  
  39.                 And then rebuild and retest.  Assuming that all related
  40.                 changes were contained in the sub directory, this should 
  41.                 isolate the change to a directory.  
  42.  
  43.                 Problems: changes in header files may have occurred; I've
  44.                 found in my case that they were self explanatory - you may 
  45.                 or may not want to give up when that happens.
  46.  
  47.         . Narrow it down to a file
  48.  
  49.           - You can apply the same technique to each file in the directory,
  50.             hoping that the changes in that file are self contained.  
  51.             
  52.         . Narrow it down to a routine
  53.  
  54.           - You can take the old file and the new file and manually create
  55.             a merged file that has
  56.  
  57.                 #ifdef VER62
  58.                 routine()
  59.                 {
  60.                         ...
  61.                 }
  62.                 #else
  63.                 routine()
  64.                 {
  65.                         ...
  66.                 }
  67.                 #endif
  68.  
  69.             And then walk through that file, one routine at a time and
  70.             prefix it with
  71.  
  72.                 #define VER62
  73.                 /* both routines here */
  74.                 #undef VER62
  75.  
  76.             Then recompile, retest, move the ifdefs until you find the one
  77.             that makes the difference.
  78.  
  79. Finally, you take all the info that you have, kernel revisions, bug
  80. description, the extent to which you have narrowed it down, and pass 
  81. that off to whomever you believe is the maintainer of that section.
  82. A post to linux.dev.kernel isn't such a bad idea if you've done some
  83. work to narrow it down.
  84.  
  85. If you get it down to a routine, you'll probably get a fix in 24 hours.
  86.  
  87. My apologies to Linus and the other kernel hackers for describing this
  88. brute force approach, it's hardly what a kernel hack would do.  However,
  89. it does work and it lets non-hackers help bug fix.  And it is cool
  90. because Linux snapshots will let you do this - something that you can't
  91. do with vender supplied releases.
  92.  
  93.